Systems that enable users to perform transactions often employ a client application and a server application that communicate with each other. The server application performs the underlying work to complete the transaction, and has access to the records to which the transaction relates. Normally, a user makes a request to perform the transaction, but the server application is not directly exposed to the user. Rather, a client application provides an interface through which the user communicates. The user interacts with the client application to indicate what the user wants to do. The client application then makes the appropriate request to the server application.
Web applications that perform banking transactions, retail purchase transactions, etc., are examples of software systems that follow this model. In a typical web transaction, a front-end web server runs a client application that interacts with a user through the user's browser. The client application then communicates with the back-end server application to request that the back-end application perform the transaction the user wants to perform. For example, a user may visit a bank web site to transfer money. The bank's front-end server cluster runs a web application that receives the user's login credentials, receives the account numbers that the money is to be transferred from and to, receives the amount of money to transfer, etc. The web application then makes a request to the bank's back-end-server to have the transaction performed. During the time that the request is being processed, the client application may show its user a message such as “Please wait while your transaction is being processed.” Behind the scenes, the web application either has issued, or is in the process of issuing, a request to have the transaction performed on the back end. The message may be displayed while the application is waiting for a reply that indicates whether the transaction was completed. Banking systems are one example of a system that may work in this manner, although many systems follow this model. For example, on-line retailers may use a web application to take customer orders, where the web application communicates the order to a back-end server for processing. Similarly, users of a large-scale database typically do not access the database directly, but instead access it through user applications that make request to the underlying database system.
When a one application (the requestor) makes a request to another application (the requestee), the request may be sent according to various different models. Request/response and send-and-forget are two such models. In a request/response protocol, the requestor waits for a reply from the requestee. The reply may indicate whether the transaction has been completed. In a send-and-forget model, the requestor sends a request without waiting for, or expecting to receive, a reply. Thus, in a send-and-forget model, the request may be lost on its way to the requestee, or the requestee may fail to complete the request, and the requestor may not learn of the fate of the request.
When the request/response model is used, communication between the requestor and the requestee has traditionally been synchronous. Thus, the requestor and the requestee participate in communication that follows a conversation model, in which the requestor sends a request and the requestee sends a reply in the same conversation. In a web application, for example, a user might see a “please wait” message while this conversation is open and while the reply is being awaited. But synchronous communications is sometimes not practical, since it may consume the resources of the requestor and requestee while they both keep the conversation open. Thus, the sending of requests may be done asynchronously through a store-and-forward model in which a message broker receives requests from the requestor and transmits requests to the requestee asynchronously.
However, asynchronous transmission of requests leaves open the possibility that a reply might be received long after the request is made. A request might be queued at the message broker for some time after it was sent by the requestor, but before being forwarded on to the requestee. Thus, there is a possibility that the requestee might issue a reply long after a synchronous conversation with the requestor would have timed out. A reply may be generated that is not part of any synchronous conversation. At least in some contexts, mechanisms have not been available to handle such replies.